Internet Toolkit/Internet Toolkit.iso/info/usbic

Text File | 1993-04-05 | 24.2 KB | 536 lines

USBIC - United States Board of IRC Co-ordinators

This document was based upon the one created for OzBIC -- written by
Elizabeth Reid ([e-mail]).

1. All administrators and operators of servers within the USA connected
   to any USBIC server shall be members of USBIC, and abide by the
   USBIC rules.

2. The names, email address, and server affiliation of all USBIC
   members should be freely available for FTP.

 2.1 All server administrators who are able to make such a list
     available for FTP must do so, and must advertise its availability
     in their server's MOTD.

3. The USBIC rules should be freely available for FTP.

 3.1  All server administrators who are able to make the rules available
      for FTP must do so, and must advertise its availability in their
      server's MOTD.

4. Voting is not compulsory where there is a call for votes on an
   USBIC matter, however all USBIC members must have the opportunity
   to vote.

 4.1 Everything possible must be done (including making long-distance
     telephone calls to vacationing USBIC members) to ensure that
     members have a chance to vote.

 4.2 Except where otherwise noted, voting periods must last for a
     minimum of seven days, or until all USBIC members have voted. At
     the conclusion of the voting period the vote taker must post the
     vote tally and the E-mail addresses and names of the voters,
     indicating whether they voted yes or no, to all the members of
     USBIC.

 4.3 Except where otherwise noted, a simple majority vote is needed
     to pass an issue.

 4.4 Once a matter has been decided by a vote, all members shall
     accept that decision, and co-operate in any manner necessary to
     implement any consequences of that decision, regardless of their
     own feelings or vote.

   4.4.1 Because they do not partake in the vote, this does not mean
         that they are not bound by the decision. Ample time will be
         given for them to comply. "Ample Time" will be decided at
         vote-taking time.

 4.5 An USBIC member may indicate that they do not wish to partake in
     USBIC discussions or voting for a specified period by notifying
     the other members of USBIC, for instance if they are going on
     vacation and do not wish to be disturbed.

5. There will be a MODERATED mailing list for USBIC members where all
   official USBIC related discussion will go.

 5.1 The moderator of the USBIC mailing list will be elected by the
     members of USBIC. A new moderator may be appointed at any time by a
     vote of USBIC members.

 5.2 Any rejected articles by the moderator will be returned to the
     sender with a short explanation why it was rejected.

6. There will be an active routing plan to provide an optimal structure
   for all servers.

 6.1 This plan will provide adequate backup links that will provide for
     major network failures.

 6.2 Procedures for where and when dynamic routing changes should be
     made will also be mentioned in the above plan.

 6.3 New plans can be implemented once a new plan is proposed, voted on,
     and accepted by the USBIC members.

 6.4 Information shall be made publically available together with the
     other information detailed above.

#####      RULES FOR IRC SERVER ADMINISTRATORS AND OPERATORS       #####

(This section of the USBIC rules is based on the OzBIC rules written by
Darren Reed ([e-mail]) and Elizabeth M. Reid
([e-mail]))

1. All server administrators must have an account on the machine which is
   running the IRC server software.

 1.1 Server administrators must have written (email) system
     administrator approval to run the irc server.

2. Servers must provide (via the A: line) valid email addresses for
   each server administrator who is responsible for that server.

 2.1 Email addresses for the server administrator must be on a local
     machine, and must not forward off-site. Exceptions will be made
     where the USBIC body has granted permission for non-local email
     addresses.

 2.2 Email addresses listed which are aliases should give a list of the
     recipients whenever the mail server (ie sendmail) is presented with
     a valid EXPN command (from the SMTP protocol).

3. The only people who are allowed access to the server's configuration file
   are those who are recognised as the server administrators as defined
   above.

4. Modified source shall not be used unless it meets the following criteria:

 4.1 It is not a test or experimental server. Test and/or experimental
     servers have no place on the main net until they are no longer
     tests and/or experiments.

 4.2 The modifications are made publicly available, preferably via
     anonymous ftp.  A copy of this must also be sent to the
     maintainer of the IRC server source code for review.

  4.2.1 The place of availability must be easily reachable by all members of
        the internet (ie firewalled public anonymous ftp sites are not
        acceptable).

 4.3 The server while running must clearly indicate by way of the
     patchlevel the modifications/origins of the modifications.
     Failure to do this contravenes the GNU Public License under which
     the IRC server is registered.

 4.4 If any server administrator is aware of a server running code
     which does not conform to the above rules he or she is required
     to inform all members of USBIC.

5. Additional IRC operators may be appointed at the discretion of the
   server administrator(s) under the following conditions:

 5.1 Operators must be sent a copy of the USBIC rules, and must
     indicate their compliance with them before being given an O-line.

 5.2 Server administrators must notify the members of USBIC of any new
     operators on their servers, and must circulate copies of that new
     operator's letter of agreement to abide by USBIC rules.

   5.2.1 The O-line for the operator may not be activated until a
         one-week period from when the USBIC members were notified has
         passed.

 5.3 An operator's O-line must be removed by the relevant server
     administrator(s) if a majority vote of the USBIC membership calls
     for it.

 5.4 Server operators on a server must all connect from nearby hosts.
     (no out-of-region hosts).

   5.4.1 It is acceptable for server administrators to have operator
         status on their up and down links as long as all parties
         involved are registered members of USBIC.  This access should
         not be treated as a condition for the server to be accepted nor
         should it be considered as mandatory.

   5.4.2 If there is a good reason for the existence of a non-local
         operator on a server, the administrator(s) of that server may
         petition the other members of USBIC for permission, by calling
         for a vote on the matter. The distance from the out-of-region
         operator to the server should be minimal. Outside of the
         country is unacceptable.

6. All server administrators are required to keep their server
   configuration files up to date. In this context, `up to date' means
   no longer than 24 hours after the administrator becomes aware of the
   need to change the configuration file, and no longer than one week
   in any case. This includes (but is not limited to) the following:

 6.1 Ensuring they are running *the* most recent server version. A two
     week grace period will be given for servers to upgrade to the most
     stable latest server version. Old versions will not be tolerated.

   6.1.1 Hub servers must upgrade to the most recent patch level
         within 24 hours.

 6.2 Ensuring that C/N lines for servers which no longer run are not left
     in an `active' state.

 6.3 Ensuring that all C/N lines for servers have passwords;

 6.4 Ensuring that O-lines are set up in such a way as to only allow
     connections that conform to previously mentioned restrictions;

 6.5 (for non-hub servers) With the appropriate use of I-lines, restrict
     access to your server to that server's immediate domain plus whatever
     currently used sites are closest.  These I-lines will be revised as
     the need arises.

 6.6 (for hub servers) ensuring that all links for leaf servers shall be
     "L: lined" (leaf-only) so to prevent leaf servers from routing
     traffic.

7. Administrators who remove their server from operation for some
   period of time are requested to inform people in advance by at
   least 24 hours (preferably more) so that appropriate measures can
   be taken to ensure there is minimum risk to the IRC network.
   Notification should be via the (to be formed) usbic mailing list,
   operlist, and alt.irc (for the users). It is suggested that the
   administrator in question put the information in their /MOTD.

8. Servers or server administrators found to be in breach of any of
   the above rules should be asked to rectify the problem.

 8.1 If any breaches of the above rules are not rectified within three
     days (four days if over a weekend) after the administrator has
     been asked to rectify them, the members of USBIC should be
     informed of the transgression.

 8.2 Once the USBIC membership has been notified of the breach, if a
     server administrator found to be in breach of any of the above
     rules refuses to rectify the situation and cannot provide any
     any reasons which USBIC members find valid for the breach, the
     administrators of servers which link to the offending server
     should co-operate with US, and regional routing coordinators
     to ensure that all links for the offending server are commented
     out, and servers which need them have alternative links.

 8.3 Links which have been commented out may be reinstated within 1
     week if the offending operator rectifies the problem. If the
     problem is not rectified within 1 week links to the offending
     server should be removed entirely.

  8.3.1 Server administrators who have had their links cut after being
        found to have breached USBIC rules may apply to have their
        links reinstated by following the USBIC Rules for the
        Establishment of New Servers.

9. Server administrators must not allow their server to be used for
   the interception of or tampering with of any network traffic,
   unless they have the appropriate legal permissions to do so.

 9.1 If such permissions do exist the administrator(s) of the server
     being used to intercept or tamper with traffic must (unless
     specifically prohibited from doing so by the appropriate legal
     authorities) provide the administrators of all servers which link
     to his or her server with a copy of the documents giving that
     permission.

  9.1.1 Administrators who have been made aware of the existence of
        any such permissions must treat that knowledge as
        confidential.

 9.2 Any server operator who becomes aware of any use of an IRC
     server to intercept or tamper with network traffic must take the
     following actions:

  9.2.1 inform the administrator(s) of the server involved of his or
        her suspicions, and provide the administrator(s) with copies
        of any evidence that has been found.

  9.2.2 inform the administrators of those servers which connect to
        the suspect server of his or her suspicions, and provide the
        administrators with copies of any evidence that has been
        found.

 9.3 Administrators of servers who are informed that a server for
     which they have links is suspected of using that server to
     intercept or tamper with network traffic should take the
     following actions:

  9.3.1 If the administrator is aware of any relevant permissions
        having been granted, the person who has brought their
        suspicions to the knowledge of the administrator should be
        told of this.

  9.3.2 If the administrator is not aware of any relevant permissions,
        he or she should cooperate with any other servers which link
        to the suspect server to ensure that all links for the
        offending server are commented out, and that servers which
        need them have alternative links, and should then inform all
        other members of USBIC of the reason for the quarantine.

  9.3.3 If, within 1 week of links for the suspect server being
        commented out, the administrator(s) of the server are unable
        to produce proof of any permissions allowing him or her to
        intercept or tamper with network traffic, links for that
        server should be permanently cut. Proof of permission includes:
        a warrant or court order, a written request from the computing
        center. Other justifications might be permitted. They will be
        dealt with on a case-by-case basis.

  9.3.4 If there is more than one server administrator at the suspect
         site, and it can be shown that only one knew about and was
         responsible for the illegal interception of or tampering with
         of network traffic, then the offending server administrator
         should be removed from his or her position, the server should
         be recompiled, and links to the server should be reinstated.

  9.3.5  A server administrator who has lost his or her links after
         breaching rule 9 may not apply to have links reinstated,
         however application may be made to establish a server at the
         same site with different server administrator(s).

 9.4 Administrators who, through the normal course of debugging or
     maintaining the server, capture traffic not explicitly destined
     for them will not be considered to be in breach of rule 9, but
     must keep the contents of that traffic strictly confidential, and
     destroy any information not directly related to their
     administrative task.


#####          RULES FOR CO-ORDINATING SIMPLE DECISIONS,            #####
#####           AND AVOIDING UN-NECESSARY VOTING                #####

(This section of the USBIC rules was based on the OzBIC Rules was
written by Daniel Carosone ([e-mail]))

1. This position is intended to simplify the process of implementing
   common-sense decisions without needing to invoke the entire voting
   mechanism of USBIC, as well as to provide a single person to handle
   simple day-to-day matters with the minimum of fuss. Any decision
   made by the primary co-ordinator of a domain may be questioned at
   any time by an USBIC member, and if necessary challenged by a vote.

2. Each hostmasked domain shall, by whatever means chosen internally
   by the members of that domain, appoint one person as the main
   contact for that site. By default this will be the administrator
   of the main server for that site, but may be any recognized USBIC
   member from that site.

 2.1 Each site will be represented on a regional board. The regions will
     be defined in the routing plan, and the number will be determined
     later. The USBIC members of each region will then elect a person
     to represent the best interests of that region to USBIC.

 2.2 The primary routing co-ordinator for the US shall be appointed by
     vote of the USBIC membership. He/She will work in conjunction with
     the information provided by regional routing co-ordinators to
      maintain and modify the routing plan as necessary.

 2.3 Someone may not be regional co-ordinator for more than one region.
     However, a person may be a regional co-ordinator and a primary
     co-ordinator if the vote favors it.

 2.4 All routing co-ordinators may be removed from their position if the
     region votes in favor of a new co-ordinator.

3. The main contact for each domain shall be the person to contact for
   all routine administrative details pertaining to that domain.

4. The main contact of each domain is responsible for organizing
   and maintaining such things as routing within the domain, and
   all external links to/from servers in that domain.

 4.1 The main contact should consult with the regional co-ordinator
     when making arrangements involving other servers in the region.

5. The regional co-ordinator is empowered to direct and make decisions
   about how various servers and networks should link together to form
   the most sensible and efficient regional structure.

 5.1 Except in cases where the changes will constitute a change in
     the overall routing plan for the US. In which case, the primary
     routing co-ordinator must be consulted.

6. All changes in domain, regional, or national level routing will
   be documented by the relevant co-ordinators.

#####        RULES FOR THE ESTABLISHMENT OF NEW IRC SERVERS        #####

(This section of the OzBIC rules is based on the European Board of IRC
Co-ordinators' (EBIC) "RULES FOR ESTABLISHING NEW IRC SERVERS IN
EUROPE". Modifications by Elizabeth M. Reid ([e-mail])).
In turn, it has been modified for USBIC by Helen Rose ([e-mail]).

1. Establishment of a new server should be a local toplevel domain
   (country) decision.

 1.1 Any person wishing to establish a new server should send email to
     the administrator(s) of the potential uplink server giving
     reasons (eg. number of users at the proposed site) for the
     request, together with other relevant details about themselves,
     about the machine and network connectivity and so on.

 1.2 The administrator(s) of the potential uplink server must send
     the candidate administrator a copy of the USBIC rules.

 1.3 The potential uplink administrator(s) must also send email to the
     system administrator at the candidate site, informing him or her of
     the request for links for an IRC server, and asking for confirmation
     of his or her permission to run the server.

  1.3.1 This should be done even if the candidate system administrator
        claims to be the system administrator at the site in question.
        If necessary, a phonecall should be used as a follow-up. Being
        listed as the NIC contact for the site is sufficient proof.

 1.4 If the candidate agrees to abide by USBIC rules, and permission
     from the system administrator at the proposed new site has been
     given, the potential uplink administrator(s) must mail all other
     members of USBIC, via the moderated USBIC mailing list,  stating
     the reasons why a new server should be established, and calling
     for a vote on the matter. Copies of the candidate administrator's
     agreement to abide by USBIC rules, and of the system
     administrator's permission to run an IRC server, must also be
     forwarded to the members of USBIC.

 1.5 If the vote is successful, the primary routing co-ordinator will
     classify the new server into a region, and the regional routing
     co-ordinator will find the best place(s)to give links to the new
     server.

  1.5.1 If the vote is unsuccessful, no petitions for a new server
        from that site will be allowed for three weeks.  After which
        the server may re apply for the establishment of a new server.

2. New servers must serve a probationary period, any condition of
   which can be ended if a majority of USBIC members agree to it.
   Probationary conditions are:

 2.1 New servers should be leafed until their administrator(s) have
     sufficient experience to handle their server responsibly. (This
     avoids routing disasters).

 2.2 A link for only ONE server should be given to the new server
     site.

 2.3 At the end of two weeks the probationary period is automatically
     ended.  The server may now be fully implemented in any routing
     decided upon by the regional routing co-ordinator.

  2.3.1 If during the probationary period, complaints are raised to the
        new server, after two weeks a vote will be called on to decide
        if the probationary period should be extended for another
        two weeks.

3. If a server administrator wishes or needs to switch from running
   the server on one machine at a particular site to another machine
   at the same site, this does not constitute a new server, and does
   not require a vote. Server administrators should arrange these
   changes amongst themselves, and inform the USBIC members of the change.

4. If administration of a current server changes, the server will
   will have to undergo a new probationary period.

5. Server administrators must ensure that if a domain hostmask link is
   given, all servers of that domain can connect to the masked server.
   (this should avoid disagreement between several hub administrators
   in one domain).

6. Where there is more than 1 server running at an organization and due
   to whatever circumstances they are not able to be connected to each
   other a vote should be taken by USBIC members to decide if either
   server is necessary.

 6.1 Where there is more than one server running on hosts within the same
     domain a host mask should be used whenever a server forms a connection
     with an IRC server external to that organisation.


#####        RULES FOR EFFECTING CHANGES TO THE USBIC RULES        #####


(This section was written by Elizabeth M. Reid ([e-mail]) and
is based on the rules for creating new Usenet newsgroups written by
Gene Spafford) Again, modified by [e-mail]

1. Any USBIC member may propose a change to the USBIC rules by
   informing all other members of the proposal.

2. Changes to USBIC rules may be effected as follows:

 2.1 Proposed changes must be posted to all USBIC members, and a
     discussion period of at least two weeks must pass before a vote
     can be called.

 2.2 After a minimum of two weeks have passed since the call for
     discussion, a call for votes may be issued. The voting period
     must last for at least two weeks and the time at which voting
     will close must be posted along with the call for votes.

 2.3 At the end of the voting period the vote taker must post the vote
     tally and the E-mail addresses and names of the voters,
     indicating whether they voted yes or no, to all the members of
     USBIC. The moderated USBIC list, mentioned above, will be used for
     the purpose of tallying votes. The moderator of the USBIC mailing
     list will do the tallying and announce the results in a timely
     fashion.

 2.4 If there are any corrections to be made to the vote tally they
     must be made within 1 week of it being posted. Any corrections
     must be taken to account when calculating the final vote tally.

 2.5 If, after corrections, there is a 2/3 (two thirds) majority in
     favour of the change to the USBIC rules, the person who called
     the vote may change the USBIC rules, and distribute the new set
     of rules to all members of USBIC, to alt.irc, and to all the FTP
     sites which carry the rules.

3. Rules cannot be applied retroactively. No member can be held to
   task for rules which did not exist at the time of any behaviour
   which is later ruled against.

4. Rules will be unilateral.  All servers must comply with new rules
   which have been voted on, and passed.  If server do not comply with
   the rules, proper procedures for servers breaking USBIC policies
   will be followed.


OBVIOUS CHANGES FROM DRAFT #1:

Voting Procedures for adoption of USBIC

1. Voting will be limited to the servers on the "list of servers" posted
to alt.irc and to the ftp site h.ece.uiuc.edu:/irc/servers.930301
2. Each server gets one vote. Servers at a site run by the same admin
and/or servers that link together get one vote. (e.g. csa.bu.edu and
csd.bu.edu are run by the same admin) Servers behind a hostmask get one
vote.
3. Each *admin* gets one vote. Even if the admin controls multiple
servers at multiple sites.
4. Only USBIC members can vote.

Organization of USBIC

1. USBIC will have a council of members. This allows busy administrators
not to have to be part of day-to-day decisions, yet allows all areas of
the country to have a say.

 1.1 The council will be made up of regional co-ordinators. The regions
     they represent will be determined along with the accepted routing
     plan.

  1.1.1 Each region shall elect its own representative to the USBIC
        council. They shall form their own voting procedure at the local
        level.

  1.1.2 Each region will have veto power over the USBIC council on
        whether a new server in their region should be added or not.
        The idea is that only the local people know the impact of a
        local server or not. But the local people must have 80% approval
        of the /admins of the region for a veto.